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METHOD AND TOKEN FOR AUTHENTICATING A 
CONTROL POINT 

FIELD OF THE INVENTION 

The present invention generally relates to a method and apparatus for authenticating 
an action. More particularly, the present invention relates to a method and token for 
authenticating a control point in a transaction or action. 

£ DESCRIPTION OF RELATED ART 

= = Financial transaction such as payment at a point of sale (POS) or the dispensing of 

T monies at an ATM machine often include authorization of the user or purchaser by the 
CO entity providing the service, payment or object desired. The user or purchaser must often 
52 present identification for the authentication such as a card (e.g. a credit card or debit card) 
l tf or a badge in order for the entity to authorize a particular action. The entity (e.g. , 

merchant) may then verify the identity of the user through information that is then conveyed 
by the card, badge or other structure presented by the user. For example, a purchaser may 
provide a credit or debit card to a merchant who runs it through a card scanner to read out 
financial identification (ID) associated with the card. The financial ID and the cost of the 
15 goods or services may be forwarded over a telephone network (such as the public switched 
telephone network) to the bank or other entity providing the credit for the credit card or 
maintaining the money associated with the debit card. The bank verifies that there is 
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sufficient credit or debt capacity for the transaction and forwards verification to the 
merchant. The consumer then is typically asked to sign a receipt for the purchase and the 
transaction is thereby completed and the goods or services are conveyed to the consumer. 
However, in these transactions, the user or purchaser must trust the entity that he is 
5 presenting his identification card or badge. The entity to whom he presents his 

identification may be a fraudulent entity and may steal vital data or monies from the user. 

Under current methods, the user or purchaser is unable to verify the authenticity of 
the entity other than observing the brand name, label or name of the entity. Any 
uncommon occurrence such as a malfunction at the entity makes the user feel 

1 o : uncomfortable . 

Secure electronic transactions (SET) have recently been used for secure credit card 
~ payments over the Internet. In a remote payment SET, both the purchaser and the 

merchant may entrust the same organization to perform an off-line verification process. 
7 This off-line verification process may be in the form of cryptographic data exchange 
15^ between the purchaser and the merchant. However, secure electronic transactions do not 

address other aspects of the payment and assume that the purchaser is satisfied with the off- 
line authentication of the digital certificate that is presented by the merchant. It is desirable 
to obtain further authentication of merchants. 

SUMMARY OF THE INVENTION 

2 0 A method is provided for authenticating (or verifying) an action (e.g. financial 

action, access control, ticketing, and toll collecting) between a control point and a user. 
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The method may involve presenting a token to the control point and authenticating the 
control point using the token. 

The authentication may occur on-line between the token and a token issuer that 
issued the token to the user. 
5 The token may be a mobile communication device that communicates with the token 

issuer using a wireless communication path. The token may also communicate with the 
token issuer using a communication network of the control point. The control point may 
also authorize the action based on information provided by the token. 

A token may be provided for authenticating a control point. The token may include 
10\ a communication portion that obtains information regarding the control point and that 
. = communicates with an external entity (e.g., a token issuer) to authenticate the control point 

: based on the information. A user interface portion may be coupled to the communication 
- portion to indicate a result of the authentication to a user. 

\ { Other objects, advantages and salient features of the invention will become apparent 

15" from the following detailed description taken in conjunction with the annexed drawings, 
which disclose preferred embodiments of the invention. 



BRIEF DESCRIPTION OF THE DRAWINGS 

The invention will be described with reference to the following drawings in which 
like reference numerals refer to like elements and wherein: 
2 0 Figure 1 is a block diagram of entities involved in a financial transaction; 

Figure 2 is a flow chart showing one example of authorizing an action; 
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Figure 3 is a flow chart showing an example embodiment of authorizing an action 
according to the present invention; 

Figure 4 shows an alternative way of communicating between the token and the 
token issuer according to an example embodiment of the present invention; 
5 Figure 5 is an alternative way of communicating between the control point and the 

control point issuer according to an example embodiment of the present invention; and 

Figure 6 is a mobile communication device according to an example embodiment of 
the present invention. 

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 

10 The present invention relates to authentication of an action between a user (e.g., a 

= purchaser) and a control point (e.g., a device operated by a merchant) as will be described 
below. This may include such activities as payment at a point of sale (POS), authentication 
at an ATM machine, access control (e.g., doors), ticketing, toll collection and other similar 
types of actions. Embodiments of the present invention allow a user to authenticate an 

15 entity (hereafter referred to as a control point) on-line with the aid of supporting 

infrastructure. For example, an authenticating device (hereafter referred to as a token) may 
communicate with its own supporting and trusted infrastructure to perform the 
authentication. The infrastructure may help authenticate the control point for the user and 
authorize the action. By allowing for such verification, the user may make sure that to the 

2 0 best knowledge of the token issuer, the control point is valid and the interaction is secure. 
This may effectively disable fraudulent control points as each point can be verified by the 
user based on the trusted infrastructure. Interactions between the user and the control point 
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may be verified and authorized not only from the control point side but also from the user 
side as well. 

Figure 1 shows entities involved in an example action such as a financial 
transaction. Other entities (not shown) may also be involved. Figure 1 shows a token 
5 issuer 10 that issues a token 50 to a user 20 (such as a purchaser). Figure 1 specifically 

shows the user 20 in possession of the token 50. The token issuer 10 may be a bank, credit 
union, security agency, etc. that is responsible for issuing tokens that will be presented to 
entities (i.e., control points) in order to perform an action. The token issuer 10 may be 
associated with a database of issued tokens 15 to store information and data about the 
10 1 tokens and users. Figure 1 also shows a control point operator 30 that approves control 
'[ points such as a control point 40. The control point operator 30 may also be associated 
~ with a database of approved control points 35 to store information and data about the 

control points. The control point 40 may be any device or entity that is approved by the 
i control point operator 30 to authenticate the user. The control point 40 may be operated by 
15] a merchant. The control point operator 30 may be an entity such as a bank, credit union or 
security agency that approves control points and provides means to authenticate the users 
and tokens. The token 50 may be a device that allows the user 20 to authenticate himself to 
the control point 40. Further, the user 20 may be a person or entity that has been granted 
the token 50 by the token issuer 10 and is authorized to use the token 50 at the control point 
2 0 40. 

Figure 2 shows one example of how a control point may authenticate a user. This 
figure will be described with respect to the entities that are shown in Figure 1 . As shown 
in Figure 2, the token issuer 10 issues the token 50 in block 100. The token 50 is provided 
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to the user 20 in block 102. The token issuer 10 may store data about the token 50 in the 
database of the issued tokens 15 in block 104. The control point operator 30 may approve 
the control point 40 in block 106 and subsequently store data about the control point 40 in 
the database of approved control points 35 in block 108. In order to perform a particular 
5 action, the user 20 may present the token 50 to the control point 40 in block 1 10. The 
control point 40 may collect data (i.e., identification number or mother's maiden name) 
from the token 50 in block 1 12. The control point 40 may also interact with the control 
point operator 30 to authenticate the user 20 in block 114. The authentication may involve 
reviewing and comparing data from the token 50 with data stored in one of the databases 

10 15, 35. If the control point operator 30 or the control point 40 authenticates the token 50, 
then the control point 40 may proceed with the respective action in block 116. Otherwise, 
the control point 40 may deny the action. In order to authenticate the tokens as being 
legitimate, the token issuer 10 may make the database of issued tokens 15 available to the 
control point operator 30. 

1 5 Figure 3 shows a flow chart of an authenticating method according to an example 

embodiment of the present invention. This flow chart is merely one example embodiment 
as other embodiments are also within the scope of the present invention. Further, the order 
of the respective blocks of Figure 3 is merely illustrative as the order of the operations may 
differ in accordance with the present invention. The Figure 3 flow chart will be described 

2 0 with respect to the entities that are shown in Figure 1 . 

The token issuer 10 may issue the token 50 in block 100 and provide the token 50 to 
the user 20 in block 102. The token issuer 10 may store data (e.g., identification numbers 
or mother's maiden name) about the token 50 in the database of issued tokens 15 in block 
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104. The control point operator 30 may approve the control point 40 in block 106 and 
store data about the control point 40 in the database of approved control points 35 in block 
108. In accordance with the present invention, the operations in blocks 106 and 108 may 
occur before, during or after the operations in blocks 100, 102 and 104. 
5 The user 20 may present the token 50 to the control point 40 in block 110. The 

control point 40 may collect data from the token 50 in block 120. The token 50 or its 
underlying structure may also collect data from the control point 40 in block 120. The 
collected data may be any type of data that may be used to authenticate another entity. The 
control point 40 may interact with the control point operator 40 to authorize the user (and 

10 token) in block 122. The token 50 may interact with the token issuer 10 to authenticate the 
control point 40 in block 124. This authentication may occur on-line between the token 50 
~ and the token issuer 10. The token 50 or its underlying structure may utilize the collected 
data regarding the control point 40 to determine if the control point 40 is a proper or 
legitimate entity. If the token 50 authenticates the control point 40 and if the control point 

15 40 authenticates the token 50, then the transaction or action may properly proceed in block 
126. If both the authentications do not occur, then the action or transaction may be denied. 

In accordance with the present invention, the order of the control point collecting 
data from the token and the token collecting data from the control point may be different 
than that shown in Figure 3. Further, the order of the control point authorizing the token 

20 and the token authorizing the control point may be different than that shown in Figure 3. 

That is, other orders of these operations are also within the scope of the present invention. 

The token 50 may be of different forms as will be described below. The token 50 
or the structure to which it is attached may include electronic equipment to communicate 
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with both the user 20 and the token issuer 10. In order for the token issuer 10 to 
authenticate the control point 40, the database of approved control points 35 is made 
available for the token issuer 10. That is, the token issuer 10 may obtain information 
regarding the control point 40 from the database 35. Communication may occur between 
5 the token issuer 10 and the control point operator 30 in order to exchange the contents of 
the database of issued tokens 15 and the database of approved control points 35. The token 
50 or the structure to which it is attached may interact with the token issuer infrastructure, 
such as the token issuer 10, so that the data collected by the token 50 from the control point 
40 can be authenticated on-line using data from the database of approved control points 35 . 

10 " Communication and exchange of data between the token 50 and the control point 40 

I may be conducted by several different types of methods including but not limited to local 
~~ communication (e.g. Bluetooth) or remote communication such as the Internet. The token 

50 may employ the necessary communication equipment to access the token issuer 
' infrastructure by using GPRS or other types of wireless networks. 

is: In one example embodiment, the control point 40 may communicate with the control 

point operator 30 across a normal communications link or direct connection. The token 50 
may communicate with token issuer 10 using a wireless communication network or a direct 
connection. Further, the token issuer 10 may communicate with the control point operator 
30 across a normal communications link or direct connection. 

2 o Figure 4 shows an embodiment in which the token 50 may use the communications 

network of the control point 40 in order to communicate on-line with the token user 10. 
That is, the token 50 may communicate with the token issuer 10 by using the same 
communication network that the control point 40 uses to communicate with the control 



point operator 30. In such circumstances, the token 50 should establish a secure and 
reliable communication channel through the possibly hostile network of the control point 
40. 

Figure 5 shows an embodiment in which the control point 40 may use the 
5 communications network of the token 50 and the token issuer 10 in order to communicate 
with the control point operator 30. That is, the control point 40 may communicate with the 
control point operator 30 using the same communication network that the token 50 uses to 
communicate with the token issuer 10. 

Figure 6 shows one embodiment of a token in which the token 50 is a mobile 
10 communication device 200. The token 50 may also be a part of the mobile communication 
device. The mobile communication device 200 may include a display device 210 and a data 
= entry portion 220 such as a keypad. The mobile communication device 200 may further 
include a communication portion 230 and a portion 240 which is fitted within the mobile 
communication device 200 and adapted to receive a smart card or similar type of device 
15 containing data. The display device 210 may visually display information such as whether 
the control point is authenticated or denied. The mobile communication device 200 may 
also include a speaker (not shown) to make an audible sound authorizing or denying the 
control point 40. The communication device 230 may communicate over a wireless 
network with the token issuer 10 or may be connected by a direct communications link to 
20 the token issuer 10. The communication device 230 may be coupled by a direct 

communications link with the control point 40. The smart card may include data of the 
token 50 or user that will be used by the control point 40 for its authentication. 
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The token 50 may be a self-contained device that holds all the necessary interfaces 
such as the mobile communication device 200 shown in Figure 6 fitted with local 
communication circuits and with a tamper-proof circuit to hold the token's data. The token 
50 may also be a self-contained device such as a smart card that provides only local 
5 communication (e.g. , galvanic contact or contactless) and a user interface such as a display 
device and/or a keypad. The means in which the communication device 200 is connected 
and communicates with the control point 40 may be different than the means used to 
connect and communicate with the token issuer 10. The token 50 may also be separated 
from a communication device and connected to it when necessary. A smart card acting as a 
10" token may also be fitted into a mobile communication device or similar type of device. 

Alternatively, the token 50 may be a separate device that is coupled to the communication 
= device (e.g., by contactless interface or Bluetooth). 

Further, the token 50 may be fitted with communication facilities that can be used 
by the control point. Such a configuration may allow for authentication at passive control 
15 ; points such as door locks. The control point 40 may then establish the reliable 

communication with its operator and the control point may securely communicate the result 
of the authentication. 

In accordance with the present invention, the user may be able to receive 
information regarding the authenticity or other characteristics of the control point. The 
2 0 token may be equipped with a user interface and the supporting infrastructure should be in 
place. 

While the invention has been described with reference to specific embodiments, the 
description of the specific embodiments is illustrative only and is not to be considered as 
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limiting the scope of the invention. Various other modifications and changes may occur to 
those skilled in the art without departing from the spirit and scope of the invention. 
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WHAT IS CLAIMED IS : 



1 



1. 



A method of authenticating an action between a control point and a user, said 



2 



method comprising: 



3 



presenting a token to said control point; and 



4 



authenticating said control point using said token. 



1 2. The method of claim 1, said method further comprising a token issuer issuing said 

2 token to said user, and wherein said authenticating occurs on-line between said token and 

3 said token issuer. 

1" 3. The method of claim 2, wherein said token comprises a mobile communication 

2 = device. 

1 4. The method of claim 3, wherein said mobile communication device communicates 

2 with said token issuer using a wireless communication path. 

1 5. The method of claim 2, wherein said token communicates with said token issuer 

2 using a communication network of said control point. 

1 6. The method of claim 1, further comprising said control point authorizing said action 

2 based on information provided by said token. 
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1 7. The method of claim 1, wherein said action comprises a financial transaction. 

1 8. The method of claim 1, wherein said action comprises access control. 

1 9. The method of claim 1, wherein said authenticating comprises notifying said user 

2 whether said control point has authorization for said action. 

1 10. A method of authenticating a control point, said method comprising: 

2 obtaining information regarding said control point; and 

3 authenticating said control point based on said information. 

1- 11. The method of claim 10, wherein said information is obtained by presenting a token 

2 to said control point. 

1 12. The method of claim 11, said method further comprising a token issuer issuing a 

2" token, and wherein said authenticating occurs on-line between said token and said token 

3 issuer. 

1 13. The method of claim 12, wherein said token comprises a mobile communication 

2 device. 

1 14. The method of claim 13, wherein said mobile communication device communicates 

2 with said token issuer using a wireless communication path. 
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2 



15. The method of claim 12, wherein said token communicates with said token issuer 
using a communication network of said control point. 



1 16. The method of claim 10, further comprising said control point authorizing an action 

2 based on information provided by said token. 

1 17. The method of claim 16, wherein said action comprises a financial transaction. 

1 18. The method of claim 16, wherein said action comprises access control. 

1 19. The method of claim 10, wherein said authenticating comprises notifying a user 

2= whether said control point has authorization for said action. 

1 20. A method of authenticating an action comprising: 
% presenting a token to said control point; 

3 said control point collecting information from said token; and 

4 authenticating said token based on said information. 

1 21. The method of claim 20 further comprising a control point operator approving said 

2 control point and said method further comprises storing data about said control point in a 

3 database, and said authorizing comprises comparing said data with said information from 

4 said token. 
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1 22. The method of claim 20, further comprising storing data about said token in a 

2 database, and said authorizing comprises comparing said data and said information from 

3 said token. 

1 23. A token for authenticating a control point comprising: 

2 a communication portion that obtains information regarding said control point and 

3 communicates with an external entity to authenticate said control point based on said 

4 information; and 

5 a user interface portion coupled to said communication portion to indicate a result of 

6 said authentication to a user. 

1~ 24. The token of claim 23, wherein said communication portion authenticates said 

2 control point on-line between said token and a token issuer that issued said token. 

L: 25. The token of claim 23, wherein said token comprises a mobile communication 

T device. 

1 26. The token of claim 23, wherein said communication portion authenticates said 

2 control point using a communication network of said control point. 

1 27. The token of claim 23, wherein said action comprises a financial transaction. 

1 28. The token of claim 23, wherein said action comprises access control. 
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1 29. The token of claim 23, wherein said user interface portion notifies said user whether 

2 said control point has authorization for said action. 

1 30. The token of claim 23, wherein said user interface portion comprises a display 

2 device. 

1 31. The token of claim 23, further comprising a card that connects with said 

2 communication portion, said card containing information regarding one of said token and 
3 5 said user. 

1: 32. The token of claim 23, wherein said communication portion is temporarily coupled 

2 to said token. 
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ABSTRACT OF THE DISCLOSURE 

A method is provided for authenticating an action between a control point and a 
user. A token is presented to the control point. The control point may be authenticated by 
using the token. The token may include a communication portion that obtains information 
regarding the control point and that communicates with a token issuer to authenticate the 
control point based on the information. A user interface portion may be coupled to the 
communication portion to indicate a result of the authentication to a user. 
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METHOD AND TOKEN FOR AUTHENTICATING A 
CONTROL POINT 

FIELD OF THE INVENTION 

The present invention generally relates to a method and apparatus for authenticating 
an action. More particularly, the present invention relates to a method and token for 
authenticating a control point in a transaction or action. 

5 DESCRIPTION OF RELATED ART 

Financial transaction such as payment at a point of sale (POS) or the dispensing of 
monies at an ATM machine often include authorization of the user or purchaser by the 
I entity providing the service, payment or object desired. The user or purchaser must often 
present identification for the authentication such as a card (e.g. a credit card or debit card) 

lEf or a badge in order for the entity to authorize a particular action. The entity (e.g., 

merchant) may then verify the identity of the user through information that is then conveyed 
by the card, badge or other structure presented by the user. For example, a purchaser may 
provide a credit or debit card to a merchant who runs it through a card scanner to read out 
financial identification (ID) associated with the card. The financial ID and the cost of the 

15 goods or services may be forwarded over a telephone network (such as the public switched 
telephone network) to the bank or other entity providing the credit for the credit card or 
maintaining the money associated with the debit card. The bank verifies that there is 
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sufficient credit or debt capacity for the transaction and forwards verification to the 
merchant. The consumer then is typically asked to sign a receipt for the purchase and the 
transaction is thereby completed and the goods or services are conveyed to the consumer. 
However, in these transactions, the user or purchaser must trust the entity that he is 
5 presenting his identification card or badge. The entity to whom he presents his 

identification may be a fraudulent entity and may steal vital data or monies from the user. 

Under current methods, the user or purchaser is unable to verify the authenticity of 
the entity other than observing the brand name, label or name of the entity. Any 
uncommon occurrence such as a malfunction at the entity makes the user feel 
10 uncomfortable. 

_\ Secure electronic transactions (SET) have recently been used for secure credit card 

payments over the Internet. In a remote payment SET, both the purchaser and the 
merchant may entrust the same organization to perform an off-line verification process. 
This off-line verification process may be in the form of cryptographic data exchange 
15 between the purchaser and the merchant. However, secure electronic transactions do not 

address other aspects of the payment and assume that the purchaser is satisfied with the off- 
line authentication of the digital certificate that is presented by the merchant. It is desirable 
to obtain further authentication of merchants. 

SUMMARY OF THE INVENTION 

2 0 A method is provided for authenticating (or verifying) an action (e.g. financial 

action, access control, ticketing, and toll collecting) between a control point and a user. 
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The method may involve presenting a token to the control point and authenticating the 
control point using the token. 

The authentication may occur on-line between the token and a token issuer that 
issued the token to the user. 
5 The token may be a mobile communication device that communicates with the token 

issuer using a wireless communication path. The token may also communicate with the 
token issuer using a communication network of the control point. The control point may 
also authorize the action based on information provided by the token. 

A token may be provided for authenticating a control point. The token may include 
10J a communication portion that obtains information regarding the control point and that 
:° communicates with an external entity (e.g., a token issuer) to authenticate the control point 
= based on the information. A user interface portion may be coupled to the communication 

portion to indicate a result of the authentication to a user. 
3 Other objects, advantages and salient features of the invention will become apparent 

15; from the following detailed description taken in conjunction with the annexed drawings, 
which disclose preferred embodiments of the invention. 



BRIEF DESCRIPTION OF THE DRAWINGS 

The invention will be described with reference to the following drawings in which 
like reference numerals refer to like elements and wherein: 
2 0 Figure 1 is a block diagram of entities involved in a financial transaction; 

Figure 2 is a flow chart showing one example of authorizing an action; 
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Figure 3 is a flow chart showing an example embodiment of authorizing an action 
according to the present invention; 

Figure 4 shows an alternative way of communicating between the token and the 
token issuer according to an example embodiment of the present invention; 
5 Figure 5 is an alternative way of communicating between the control point and the 

control point issuer according to an example embodiment of the present invention; and 

Figure 6 is a mobile communication device according to an example embodiment of 
the present invention. 

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 

10 The present invention relates to authentication of an action between a user (e.g., a 

purchaser) and a control point (e.g., a device operated by a merchant) as will be described 
below. This may include such activities as payment at a point of sale (POS), authentication 
at an ATM machine, access control (e.g., doors), ticketing, toll collection and other similar 
types of actions. Embodiments of the present invention allow a user to authenticate an 

15 entity (hereafter referred to as a control point) on-line with the aid of supporting 

infrastructure. For example, an authenticating device (hereafter referred to as a token) may 
communicate with its own supporting and trusted infrastructure to perform the 
authentication. The infrastructure may help authenticate the control point for the user and 
authorize the action. By allowing for such verification, the user may make sure that to the 

2 0 best knowledge of the token issuer, the control point is valid and the interaction is secure. 
This may effectively disable fraudulent control points as each point can be verified by the 
user based on the trusted infrastructure. Interactions between the user and the control point 
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may be verified and authorized not only from the control point side but also from the user 
side as well. 

Figure 1 shows entities involved in an example action such as a financial 
transaction. Other entities (not shown) may also be involved. Figure 1 shows a token 
5 issuer 10 that issues a token 50 to a user 20 (such as a purchaser). Figure 1 specifically 

shows the user 20 in possession of the token 50. The token issuer 10 may be a bank, credit 
union, security agency, etc. that is responsible for issuing tokens that will be presented to 
entities (i.e., control points) in order to perform an action. The token issuer 10 may be 
associated with a database of issued tokens 15 to store information and data about the 
l(M tokens and users. Figure 1 also shows a control point operator 30 that approves control 
"° points such as a control point 40. The control point operator 30 may also be associated 
: : with a database of approved control points 35 to store information and data about the 

control points. The control point 40 may be any device or entity that is approved by the 
/; control point operator 30 to authenticate the user. The control point 40 may be operated by 
151 a merchant. The control point operator 30 may be an entity such as a bank, credit union or 
security agency that approves control points and provides means to authenticate the users 
and tokens. The token 50 may be a device that allows the user 20 to authenticate himself to 
the control point 40. Further, the user 20 may be a person or entity that has been granted 
the token 50 by the token issuer 10 and is authorized to use the token 50 at the control point 
2 0 40. 

Figure 2 shows one example of how a control point may authenticate a user. This 
figure will be described with respect to the entities that are shown in Figure 1 . As shown 
in Figure 2, the token issuer 10 issues the token 50 in block 100. The token 50 is provided 
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to the user 20 in block 102. The token issuer 10 may store data about the token 50 in the 
database of the issued tokens 15 in block 104. The control point operator 30 may approve 
the control point 40 in block 106 and subsequently store data about the control point 40 in 
the database of approved control points 35 in block 108. In order to perform a particular 
5 action, the user 20 may present the token 50 to the control point 40 in block 110. The 
control point 40 may collect data (i.e., identification number or mother's maiden name) 
from the token 50 in block 1 12. The control point 40 may also interact with the control 
point operator 30 to authenticate the user 20 in block 114. The authentication may involve 
reviewing and comparing data from the token 50 with data stored in one of the databases 

10 15, 35. If the control point operator 30 or the control point 40 authenticates the token 50, 
then the control point 40 may proceed with the respective action in block 1 16. Otherwise, 
the control point 40 may deny the action. In order to authenticate the tokens as being 
legitimate, the token issuer 10 may make the database of issued tokens 15 available to the 
control point operator 30. 

15 Figure 3 shows a flow chart of an authenticating method according to an example 

embodiment of the present invention. This flow chart is merely one example embodiment 
as other embodiments are also within the scope of the present invention. Further, the order 
of the respective blocks of Figure 3 is merely illustrative as the order of the operations may 
differ in accordance with the present invention. The Figure 3 flow chart will be described 

2 0 with respect to the entities that are shown in Figure 1 . 

The token issuer 10 may issue the token 50 in block 100 and provide the token 50 to 
the user 20 in block 102. The token issuer 10 may store data (e.g. , identification numbers 
or mother's maiden name) about the token 50 in the database of issued tokens 15 in block 
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104. The control point operator 30 may approve the control point 40 in block 106 and 
store data about the control point 40 in the database of approved control points 35 in block 
108. In accordance with the present invention, the operations in blocks 106 and 108 may 
occur before, during or after the operations in blocks 100, 102 and 104. 
5 The user 20 may present the token 50 to the control point 40 in block 110. The 

control point 40 may collect data from the token 50 in block 120. The token 50 or its 
underlying structure may also collect data from the control point 40 in block 120. The 
collected data may be any type of data that may be used to authenticate another entity. The 
control point 40 may interact with the control point operator 40 to authorize the user (and 
ier token) in block 122. The token 50 may interact with the token issuer 10 to authenticate the 
control point 40 in block 124. This authentication may occur on-line between the token 50 
= and the token issuer 10. The token 50 or its underlying structure may utilize the collected 

data regarding the control point 40 to determine if the control point 40 is a proper or 
3 legitimate entity. If the token 50 authenticates the control point 40 and if the control point 
15: 40 authenticates the token 50, then the transaction or action may properly proceed in block 
126. If both the authentications do not occur, then the action or transaction may be denied. 

In accordance with the present invention, the order of the control point collecting 
data from the token and the token collecting data from the control point may be different 
than that shown in Figure 3. Further, the order of the control point authorizing the token 
2 0 and the token authorizing the control point may be different than that shown in Figure 3. 

That is, other orders of these operations are also within the scope of the present invention. 

The token 50 may be of different forms as will be described below. The token 50 
or the structure to which it is attached may include electronic equipment to communicate 
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with both the user 20 and the token issuer 10. In order for the token issuer 10 to 
authenticate the control point 40, the database of approved control points 35 is made 
available for the token issuer 10. That is, the token issuer 10 may obtain information 
regarding the control point 40 from the database 35 . Communication may occur between 
5 the token issuer 10 and the control point operator 30 in order to exchange the contents of 
the database of issued tokens 15 and the database of approved control points 35. The token 
50 or the structure to which it is attached may interact with the token issuer infrastructure, 
such as the token issuer 10, so that the data collected by the token 50 from the control point 
40 can be authenticated on-line using data from the database of approved control points 35. 

10. Communication and exchange of data between the token 50 and the control point 40 

may be conducted by several different types of methods including but not limited to local 
communication (e.g. Bluetooth) or remote communication such as the Internet. The token 
50 may employ the necessary communication equipment to access the token issuer 
infrastructure by using GPRS or other types of wireless networks. 

15 In one example embodiment, the control point 40 may communicate with the control 

point operator 30 across a normal communications link or direct connection. The token 50 
may communicate with token issuer 10 using a wireless communication network or a direct 
connection. Further, the token issuer 10 may communicate with the control point operator 
30 across a normal communications link or direct connection. 

2 0 Figure 4 shows an embodiment in which the token 50 may use the communications 

network of the control point 40 in order to communicate on-line with the token user 10. 
That is, the token 50 may communicate with the token issuer 10 by using the same 
communication network that the control point 40 uses to communicate with the control 



point operator 30. In such circumstances, the token 50 should establish a secure and 
reliable communication channel through the possibly hostile network of the control point 
40. 

Figure 5 shows an embodiment in which the control point 40 may use the 
5 communications network of the token 50 and the token issuer 10 in order to communicate 
with the control point operator 30. That is, the control point 40 may communicate with the 
control point operator 30 using the same communication network that the token 50 uses to 
communicate with the token issuer 10. 

Figure 6 shows one embodiment of a token in which the token 50 is a mobile 

10 communication device 200. The token 50 may also be a part of the mobile communication 
device. The mobile communication device 200 may include a display device 210 and a data 
entry portion 220 such as a keypad. The mobile communication device 200 may further 
include a communication portion 230 and a portion 240 which is fitted within the mobile 
communication device 200 and adapted to receive a smart card or similar type of device 

15 containing data. The display device 210 may visually display information such as whether 
the control point is authenticated or denied. The mobile communication device 200 may 
also include a speaker (not shown) to make an audible sound authorizing or denying the 
control point 40. The communication device 230 may communicate over a wireless 
network with the token issuer 10 or may be connected by a direct communications link to 

20 the token issuer 10. The communication device 230 may be coupled by a direct 

communications link with the control point 40. The smart card may include data of the 
token 50 or user that will be used by the control point 40 for its authentication. 
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The token 50 may be a self-contained device that holds all the necessary interfaces 
such as the mobile communication device 200 shown in Figure 6 fitted with local 
communication circuits and with a tamper-proof circuit to hold the token's data. The token 
50 may also be a self-contained device such as a smart card that provides only local 
5 communication (e.g., galvanic contact or contactless) and a user interface such as a display 
device and/or a keypad. The means in which the communication device 200 is connected 
and communicates with the control point 40 may be different than the means used to 
connect and communicate with the token issuer 10. The token 50 may also be separated 
from a communication device and connected to it when necessary. A smart card acting as a 

1 0 token may also be fitted into a mobile communication device or similar type of device. 

Alternatively, the token 50 may be a separate device that is coupled to the communication 
device (e.g., by contactless interface or Bluetooth). 

Further, the token 50 may be fitted with communication facilities that can be used 
by the control point. Such a configuration may allow for authentication at passive control 

1 5 points such as door locks. The control point 40 may then establish the reliable 

communication with its operator and the control point may securely communicate the result 
of the authentication. 

In accordance with the present invention, the user may be able to receive 
information regarding the authenticity or other characteristics of the control point. The 

2 0 token may be equipped with a user interface and the supporting infrastructure should be in 
place. 

While the invention has been described with reference to specific embodiments, the 
description of the specific embodiments is illustrative only and is not to be considered as 
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limiting the scope of the invention. Various other modifications and changes may occur to 
those skilled in the art without departing from the spirit and scope of the invention. 
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WHAT IS CLAIMED IS : 



1 1 . A method of authenticating an action between a control point and a user, said 

2 method comprising: 

3 presenting a token to said control point; and 

4 authenticating said control point using said token. 

1 2. The method of claim 1, said method further comprising a token issuer issuing said 

2 token to said user, and wherein said authenticating occurs on-line between said token and 

3 said token issuer. 

1 3. The method of claim 2, wherein said token comprises a mobile communication 

2 device. 

0 4. The method of claim 3, wherein said mobile communication device communicates 
2 with said token issuer using a wireless communication path. 

1 5. The method of claim 2, wherein said token communicates with said token issuer 

2 using a communication network of said control point. 

1 6. The method of claim 1, further comprising said control point authorizing said action 

2 based on information provided by said token. 
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1 



7. 



The method of claim 1, wherein said action comprises a financial transaction. 



1 8. The method of claim 1, wherein said action comprises access control. 

1 9. The method of claim 1 , wherein said authenticating comprises notifying said user 

2 whether said control point has authorization for said action. 

1 10. A method of authenticating a control point, said method comprising: 

2 obtaining information regarding said control point; and 

3.: authenticating said control point based on said information. 

1 11. The method of claim 10, wherein said information is obtained by presenting a token 

2 to said control point. 

1- 12. The method of claim 1 1 , said method further comprising a token issuer issuing a 

X token, and wherein said authenticating occurs on-line between said token and said token 

3 issuer. 

1 13. The method of claim 12, wherein said token comprises a mobile communication 

2 device. 

1 14. The method of claim 13, wherein said mobile communication device communicates 

2 with said token issuer using a wireless communication path. 
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1 15. The method of claim 12, wherein said token communicates with said token issuer 

2 using a communication network of said control point. 



1 16. The method of claim 10, further comprising said control point authorizing an action 

2 based on information provided by said token. 

1 17. The method of claim 16, wherein said action comprises a financial transaction. 

1 18. The method of claim 16, wherein said action comprises access control. 

1 19. The method of claim 10, wherein said authenticating comprises notifying a user 

2- whether said control point has authorization for said action. 

1 20. A method of authenticating an action comprising: 

2 presenting a token to said control point; 

3 said control point collecting information from said token; and 

4 authenticating said token based on said information. 

1 21 . The method of claim 20 further comprising a control point operator approving said 

2 control point and said method further comprises storing data about said control point in a 

3 database, and said authorizing comprises comparing said data with said information from 

4 said token. 
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1 22. The method of claim 20, further comprising storing data about said token in a 

2 database, and said authorizing comprises comparing said data and said information from 

3 said token. 

1 23. A token for authenticating a control point comprising: 

2 a communication portion that obtains information regarding said control point and 

3 communicates with an external entity to authenticate said control point based on said 

4 information; and 

5 a user interface portion coupled to said communication portion to indicate a result of 

6 said authentication to a user. 

1 24. The token of claim 23, wherein said communication portion authenticates said 

2 control point on-line between said token and a token issuer that issued said token. 

1 25. The token of claim 23, wherein said token comprises a mobile communication 

2 device. 

1 26. The token of claim 23, wherein said communication portion authenticates said 

2 control point using a communication network of said control point. 

1 27. The token of claim 23, wherein said action comprises a financial transaction. 

1 28. The token of claim 23, wherein said action comprises access control. 
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1 29. The token of claim 23, wherein said user interface portion notifies said user whether 

2 said control point has authorization for said action. 

1 30. The token of claim 23, wherein said user interface portion comprises a display 

2 device. 

1 31. The token of claim 23, further comprising a card that connects with said 

2 communication portion, said card containing information regarding one of said token and 

3 said user. 

1= 32. The token of claim 23, wherein said communication portion is temporarily coupled 

2 to said token. 
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ABSTRACT OF THE DISCLOSURE 

A method is provided for authenticating an action between a control point and a 
user. A token is presented to the control point. The control point may be authenticated by 
using the token. The token may include a communication portion that obtains information 
regarding the control point and that communicates with a token issuer to authenticate the 
control point based on the information. A user interface portion may be coupled to the 
communication portion to indicate a result of the authentication to a user. 
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